Life, Liberty, and the Pursuit of Agility

Many of us have worked with a defined process such as “The Waterfall”, and it seems like it should work – but there are numerous shortcomings that can be attributed to following this developemnt approach  and that’s what I’ll explore.So what exactly is “Waterfall”?

The basics of waterfall:

• Waterfall is a sequential, phased model of software development project management.
• It has a strong “predictive” nature to it.
• A phase is a period of time during which a block of work is done with a deadline and a deliverable.
• The typical phases are named things like Requirements Gathering, Analysis, Design, Coding, Testing, Deployment, Production.
• The deliverable from a phase is “signed-off”, “base-lined”, and “handed-off” to the next phase.
• The work of one phase is based on the work of the previous phase – the work “cascades” from one phase to another, and thus the term “Waterfall”
• Each phase typically has its own team.
• Cross-phase communication is mostly via documents, diagrams, models, etc.
• On large projects teams sometimes work at different locations.
• People on earlier phases are often “rolled-off” at the end of the phase.

Seems to makes sense: people see this as being logical and understandable.

Waterfall has Failed

Of course, that is up for debate, but in my opinion there are so many problems with the Waterfall approach that it isn’t worth considering for most projects, and especially not larger projects.  The sequential and predictive approach is ill suited to complex and novel endeavors (like software development) which require an empirical approach that allows us to continually inspect and adapt.  There are some environments where a predictive approach like Waterfall is mandated, and it might be impossible to introduce Agile practices in that case. 

A few of the problems I intend to explore in future posts:

• Communication issues (over-reliance on documents)
• The “up-front” work problem
• The “sign-off” problem
• The “base-lined” problem
• The “hand-off” problem
• The “deadline” problem
• No (decent) way to judge progress
• It’s a “fail-late” process – it hides problems.
• No useful feedback mechanism
• Overwhelming opportunities for waste
• No reasonable way to deal with changes
• Don’t get me started

Next time I post about Watefall, I’ll start in on the Communication Issues of Waterfall.  Development using a waterfall approach is hampered by an emphasis on “communication-by-documentation”.